25. Projekt zespołowy - tydzień 3 z 3

Jak wiesz, projekt zespołowy był prowadzony w metodyce Kanban. Najpewniej wiesz, że bardzo popularna jest inna metodyka — Scrum. Czym one się różnią, a co je łączy? Dlaczego wybraliśmy Kanban? W tym rozdziale odpowiemy na te pytania.

Agile, czyli zwinność

Wraz z rozwojem technologii oraz wymagań rynku, zmieniały się również metodyki pracy w zespołach wytwarzających oprogramowanie. Naturalną metodą pracy jest metoda kaskadowa, znana również jako waterfall. Zakłada ona, że kolejne etapy pracy nad produktem muszą następować po sobie, a każdy etap musi być zamknięty, zanim rozpocznie się kolejny. Przy tej metodzie jednak czas realizacji projektu jest długi, a sam projekt mało elastyczny, kiedy wymagania ulegają zmianie.

Z tego powodu rozpoczęto poszukiwania innych metod, które pozwoliłyby na lepsze dostosowywanie projektu do zmieniających się wymagań. W ten sposób powstała filozofia metodyk zwinnych – Agile. Obecnie do najpopularniejszych technik typu Agile należą Kanban i Scrum. Ponieważ wychodzą one z jednakowych założeń, wiele ich elementów jest podobnych. Podstawowe założenia tych technik i różnice między nimi omówimy sobie za chwilę, najpierw jednak zastanówmy się: dlaczego w projekcie czasem przydaje się zwinność? Czy zwinne podejście sprawdza się w każdym przypadku?

Wyobraź sobie, że pracujesz w firmie, która zajmuje się tworzeniem aplikacji webowych i stron internetowych na zlecenie klientów. Zwykle klienci przychodzą z kompletną specyfikacją i designami, i od gotowego produktu wymagają tylko tyle, by zgadzał się z wizualizacją, działał według opisu, i został dostarczony w ustalonym czasie. Developerzy, zapoznawszy się ze specyfikacją, uznają, że mogą zakodować projekt z użyciem dobrze znanych im technologii. Dział sprzedaży w firmie może w takim przypadku łatwo wycenić projekt, przesłać klientowi stabilny kosztorys i termin realizacji, a dział IT, wiedząc, że wymagania klienta nie zmienią się, spokojnie może rozplanować pracę z użyciem tradycyjnej metody kaskadowej.

Czasem jednak zdarza się, że do firmy przychodzi klient, który nie ma całościowej wizji tego, jak ma wyglądać i działać jego produkt. Taka sytuacja zdarza się często, gdy produkt ma być innowacyjny i klient nie wie jeszcze, jak się sprawdzi i jak zostanie przyjęty przez odbiorców. Może trzeba będzie w pewnym momencie całkowicie zmienić kierunek jego rozwoju – kto wie? Klient chciałby blisko współpracować z działem IT, na bieżąco zgłaszać uwagi i korekty, szybko otrzymać działającą wersję produktu, oraz móc w regularnych odstępach czasu wprowadzać w nim nowe funkcjonalności. W tym przypadku użycie metody kaskadowej jest niemożliwe – klient nie jest w stanie na samym początku projektu dostarczyć ostatecznej wersji specyfikacji, a dział IT musi być przygotowany na nagłe zmiany koncepcji.

To drugie, zwinne podejście bardzo często znajduje też zastosowanie, kiedy dział IT wykonuje zlecenia dla innych działów tej samej firmy. Np. dział Marketingu może potrzebować szybko reagować na zmiany u konkurencji i w zależności od bieżących potrzeb zmieniać specyfikacje zaplanowanych projektów.

Kanban

W projekcie grupowym używaliśmy techniki zarządzania projektami zwanej Kanbanem. Pokrótce omówiliśmy sobie tę metodologię szerzej w module dot. OOP, ale szybko przypomnimy jej podstawy.

W Kanbanie jest wiele zadań. Niektóre z nich mogą zależeć od innych, ale zdecydowana większość jest niezależna. Każdy członek zespołu bierze sobie zadanie ze szczytu puli zadań do zrobienia, oznacza jako zadanie rozpoczęte, a po zakończeniu prac oznacza jako skończone.

W najprostszej implementacji Kanbana tablica zadań może wyglądać tak:

Jak widzisz, tablica Kanban w naszym projekcie była nieco bardziej rozbudowana, ale działała na tej samej zasadzie. Sukcesywnie przenosiliśmy taski z lewej strony tablicy (kolumna “To do”) na prawą (kolumna “Done”), dzięki czemu stan projektu i stopień jego wykonania był jasny dla każdego, kto spojrzał na tablicę.

Oprócz wizualizacji procesu Kanban zakłada ograniczenie liczby zadań będących w toku (stąd w naszym projekcie limit zadań, które jeden developer może mieć w danym momencie “in progress”). Wszystko to ma na celu optymalizację pracy zespołu i wyłapywanie “wąskich gardeł” (np. sytuacji, gdy zespół developerski ma otwartych bardzo wiele zadań, a zespół kontroli jakości nie ma w tym samym czasie niczego do testowania).

Największą zaletą Kanbana jest ciągłe dostarczanie efektów. Zadania są realizowane równolegle i nie wymagają planowania czy czekania na rozpoczęcie kolejnego etapu. Dodatkowo, osoby realizujące projekt mogą wybierać zadania z zakresu, w którym się specjalizują. Dzięki temu są bardziej zaangażowani w proces powstawania projektu i mają wpływ na kierunek rozwoju swoich umiejętności.

Kanban a Scrum

Podczas gdy Kanban jest głównie narzędziem do organizacji zadań w projekcie, Scrum jest rozbudowanym frameworkiem (szkieletem, zestawem narzędzi), który pozwala realizować założenia zwinnych projektów.

Co więcej, tablica Kanban może być wykorzystywana również w Scrumie, do wizualizacji postępów zadań w ramach tzw. Sprintu, o którym za chwilę opowiemy. Wynika to z faktu, że Kanban skupia się na samym procesie przepływu zadań przez etapy realizacji, a Scrum definiuje zarówno cały proces realizacji, jak i role w zespole projektowym.

Role w Scrumie

Scrum wyróżnia 3 role w projekcie:

Product Owner – właściciel produktu, który jest odpowiedzialny za wizję tworzonego oprogramowania. Określa wymagania techniczne i nietechniczne (np. wygląd). Jego rola polega na wypracowywaniu wraz z klientem wspólnej wizji tworzonego produktu. Powstałe założenia trafiają do tzw. backloga (po polsku to jest "rejestr produktowy", ale mało kto używa tego określenia).

Scrum Master – zajmuje się pilnowaniem, aby projekt był wykonywany zgodnie w metodyką i założeniami frameworku. Kontroluje proces powstałego oprogramowania oraz pracę zespołu developerskiego. Przekształca założenia z backlog na zadania do realizacji w ramach sprintu.

Development Team – zespół odpowiedzialny za rozwój produktu. Nie mówimy tutaj wyłącznie o developerach, ale również o testerach, designerach oraz wszystkich osobach, które wykonują zadania w projekcie.

Warto podkreślić, że Scrum zakłada samodyscyplinę oraz odpowiedzialność każdego z członków zespołu. Dzięki zaangażowaniu możemy mówić, że zespół jest samoorganizujący się.

Organizacja pracy w Scrumie

Opisując Kanban, mówiliśmy o ciągłym dostarczaniu efektów. W Scrumie proces przebiega inaczej, ponieważ wydziela się okresy nazwane Sprintami. W Web Developmencie przeważnie trwają one od 2 tygodni do miesiąca, ale zdarzają się też innej długości, jeśli specyfika projektu tego wymaga.

Na każdy Sprint planuje się pewną ilość zadań do realizacji. Zakłada się, że każde z zadań powinno dawać konkretny efekt, np. nowa strona, nowa funkcjonalność formularza, etc. Zespół Developerski decyduje o tym, ile zadań będzie w stanie wykonać w danym Sprincie, w zależności od ich pracochłonności oraz np. dyspozycyjności członków zespołu.

Scrum jest bardzo obszernym tematem i zasługuje na osobne szkolenie, ale warto zapoznać się z najbardziej charakterystycznymi elementami jego organizacji:

• spotkanie "grooming", które polega na ocenie pracochłonności każdego zadania, lub ew. zgłoszeniu do Product Ownera wątpliwości, które uniemożliwiają oszacowanie zadania,
• spotkanie "planning", czyli przed rozpoczęciem Sprintu planuje się które elementy projektu będą zrealizowane w danym Sprincie,
• codzienne spotkania "stand-up", nazwane tak ze względu na to, że powinny być krótkie, w czym pomocne jest realizowanie ich na stojąco — w czasie takiego spotkania każdy mówi, czym się zajmował się ostatnio, co będzie robił dalej, i czy powstały jakieś problemy,
• spotkanie "review", na którym podsumowuje się przebieg kończącego się Sprintu,
• spotkanie "retrospective" (w skrócie "retro"), które następuje po "review", i skupia się na odpowiedzi na pytanie o powody zarówno powodzenia, jak i niepowodzenia w realizacji zadań, dzięki czemu z biegiem czasu sprawność pracy Zespołu Developerskiego powinna rosnąć.

W praktyce, ze względu na oszczędność czasu, często na przełomie Sprintów organizuje się jedno spotkanie, w którego agendzie jest review, retro oraz planowanie kolejnego Sprintu.

Kanban czy Scrum?

Obie techniki, które sobie omówiliśmy, mają zarówno silne, jak i słabe strony, oraz pasują do określonych typów projektów. W naszym projekcie grupowym zdecydowaliśmy się na Kanbana ze względu na to, że jest on prostszy – nie narzuca on ani struktury zespołu, ani nie wymaga zdefiniowanych iteracji (Sprintów).

W realiach naszego kursu Scrum byłby problematyczny, ponieważ przed rozpoczęciem prac musiałby się odbyć grooming, a następnie planning. Co więcej, zespół musiałby oszacować, ile uda się wykonać np. w ciągu tygodnia, a na tym etapie nauki macie prawo jeszcze nie mieć takiego wyczucia dot. pracochłonności zadań.

Z procesu Scruma pożyczyliśmy jednak do naszego projektu kilka aspektów:

• codzienne "spotkania" na komunikatorze (daily), żeby ułatwić sobie śledzenie statusów zadań oraz postępów innych członków zespołu,
• cotygodniowe spotkania, mające na celu podsumowanie postępów (review), wyciągnięcie wniosków (retro) i zaplanowanie kolejnych kroków realizacji projektów (planning).

A więc co wybrać w przypadku własnych projektów realizowany po kursie? W projektach samodzielnych zdecydowanie polecamy Kanbana. Przy małych zespołach i projektach, Kanban również się sprawdzi, ale wymienione powyżej spotkania bardzo usprawnią pracę. Jednak im większe i im bardziej skomplikowane przedsięwzięcie, tym większą przewagę będzie miał Scrum.

Ten projekt był dla Ciebie bardzo ważnym doświadczeniem, ponieważ dzięki niemu wiesz już, jak pracuje się w zespole, rozumiesz potrzebę dobrej komunikacji i organizacji projektu, a także była to dla Ciebie okazja praktycznego wykorzystania zdobytej wiedzy.

Jest jednak jeszcze jeden bardzo ważny aspekt — udział w tym projekcie zespołowym wyróżni Cię spośród innych kandydatów na stanowisko Junior Web Developera. Są spore szanse, że właśnie ten projekt będzie poruszany na każdej rozmowie rekrutacyjnej, ponieważ umiejętność pracy w zespole jest jedną z umiejętności, na które rekruterzy zwracają największą uwagę.

Zależało nam na tym, żebyście mogli w bezpiecznych warunkach przekonać się, jak mogą wyglądać pierwsze dni pracy na stanowisku Junior Web Developer. Dlatego przeprowadziliśmy wywiady z wieloma programistami, aby dostarczyć Wam jak najbardziej rzeczywiste problemy, z którymi możecie spotkać się w pracy.

Wszystko to stanowi świetny materiał na rozmowę rekrutacyjną! Poniżej znajdziesz parę wskazówek dot. tego jak najlepiej mówić o tym projekcie, aby rekruter zobaczył Twoje najlepsze strony.

Jak warto mówić o projekcie na rozmowie rekrutacyjnej?

Pamiętaj, że potencjalny pracodawca może być bardziej zainteresowany tym, co nie wyszło, niż tym, co zadziałało bez problemów. Wynika to z faktu, że w zespole liczy się umiejętność dostrzegania błędów (także swoich) i wyciągania wniosków na przyszłość.

Na rozmowie rekrutacyjnej staraj się podkreślać własne wnioski, wyciągnięte w oparciu o udział w projekcie.

Mówiąc o jakichkolwiek przeszkodach w realizacji zadań, skupiaj się na tym, jak sobie z nimi poradziliście, albo na swoich pomysłach jak można było sobie z nimi poradzić.

Nie obwiniaj innych za niepowodzenia, bo rekruterzy nie lubią tzw. recenzentów, którzy oceniają wszystkich dookoła, ale nie umieją przełożyć tego na sukces.

Warto przyznać się do jakiejś swojej słabości, np. że trudno było Ci mówić, że masz z czymś problem.

Doceniaj udział innych osób w prace nad projektem. To pokazuje, że potrafisz dogadywać się z innymi i doceniasz ich wkład w sukces.

Pamiętaj — istotne jest pokazanie, że wyciągasz wnioski z niepowodzeń i umiesz pracować w zespole. Wykorzystaj opowiadanie o tym projekcie, aby podkreślić te cechy.

Mamy nadzieję, że udało Wam się stworzyć zgrany zespół, rozwiązać pojawiające się problemy i zrealizować projekt w zakresie zadań opisanych w Jirze. Jeśli jednak tak się nie stało, nie przejmuj się! Najważniejsze było zdobycie doświadczenia w pracy zespołowej.